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METHOD OF SWITCHING 
EXTERNAL MODELS IN AN 
AUTOMATED SYSTEM-ON-CHIP 
INTEGRATED CIRCUIT DESIGN 
VERIFICATION SYSTEM 

Background of the Invention 

[0001] FIELD OF THE INVENTION 

[0002] The present invention relates to the field of testing computer system designs by 
software simulation; more specifically, it relates to an automated system for system- 
on-chip (SOC) design verification. 

[0003] CROSS REFERENCE TO RELATED APPLICATIONS 

[0004] This application is related by common inventorship and subject matter to co- 
pending applications titled "Method of Controlling External Models in System-On- 
Verification" S/N 09/494,230, "Simulator-Independent System-On-Chip Verification 
Methodology" S/N 09/494,565, "Method of Developing Re-Usable Software for 
Efficient Verification of System-On-Chip Integrated Circuit Designs" S/N 09/494,907, 
"Method for Efficient Verification of System-On-Chip Integrated Circuit Designs 
Including an Embedded Processor" S/N 09/494,564, "Processor-Independent System- 
On-Chip Verification for Embedded Processor Systems" S/N 09/494, 386, "Method for 
Re-Using System-On-Chip Verification Software in an Operating System" S/N 
09/495,236 and "Automated System-On-Chip Integrated Circuit Design Verification 
System" S/N 09/969,675. The listed applications are assigned to International 
Business Machines Corporation and are entirely incorporated herein by this reference. 
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[0005] 



BACKGROUND OF THE INVENTION 



[0006] The complexity and sophistication of present-day integrated circuit (IC) chips have 
advanced significantly over those of early chip designs. Where formerly a chip might 
embody relatively simple electronic logic blocks affected by interconnections between 
logic gates, currently chips can include combinations of complex, modularized IC 
designs often called "cores" which together constitute an entire SOC. 

[0007] In general, IC chip development includes a design phase and a verification phase 
for determining whether a design works as expected. The verification phase has 
moved increasingly toward a software simulation approach to avoid the costs of first 
implementing designs in hardware to verify them. 

[0008] A key factor for developers and marketers of IC chips in being competitive in 

*J business is time-to-market of new products, the shorter the time-to-market, the 

y! better the prospects for sales. Time-to-market in turn depends to a significant extent 

J?J on the duration of the verification phase for new products to be released. As chip 

CP designs have become more complex, shortcomings in existing chip verification 

%j methodologies, which extend time-to-market have become evident. 

!rj [0009] Typically, in verifying a design, a simulator is used. Here, "simulator" refers to 

P specialized software whose functions include accepting software written in a hardware 

Mb 

q description language (HDL) such as Verilog or VHDL which models a circuit design (for 

m example, a core as described above), and using the model to simulate the response of 

the design to stimuli which are applied by a test case to determine whether the design 
functions as expected. The results are observed and used to de-bug the design. In 
order to achieve acceptably bug-free designs, verification software must be developed 
for applying a number of test cases sufficient to fully exercise the design in 
simulation. In the case of SOC designs, the functioning of both the individual cores as 
they are developed, and of the cores functioning concurrently when interconnected, as 
a system must be verified. Moreover, a complete SOC design usually includes an 
embedded processor core and an I/O controller. Simulation, which includes a 
processor core, tends to require an inordinate amount of time and computing 
resources, largely because the processor is usually the most complex piece of circuitry 
on the chip and interacts with many other cores. Simulation, which includes an I/O 
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controller, tends to require an inordinate amount of new software or software 
modification because the specific I/O cores, pin connections, number of pins, etc. vary 
from design to design. 

[001 0] It can be appreciated from the foregoing that verification of an SOC can severely 
impact time-to-market, due to the necessity of developing and executing software for 
performing the numerous test cases required to fully exercise the design. 

[0011] However, inefficiencies in current verification methodologies exacerbate time 
pressures. For example, design specific verification software must be written or the 
existing software modified for each specific chip design to be verified. With today's 
exceedingly complex SOC designs, even modification of existing software is expensive 
and time consuming. One particularly time-consuming need is to write or modify the 
software needed for verifying I/O pin muxing of SOC cores to I/O pin driver models. 
Simulation of pin muxing presents unique challenges because some I/O pin driver 
models cannot be turned off and there is no standard established for turning on/off 
those models that can be turned on/off. 

[001 2] A design verification system is needed which will reduce the amount of chip 
specific design verification software required, especially for verification of pin- 
muxing, as well as reduce the time to collect and integrate that software. 

Summary of the Invention 

[001 3] A first aspect of the present invention is a system for verifying an integrated 

circuit design comprising: an I/O controller connected to one or more I/O cores, the 
I/O cores part of the integrated circuit design; an external memory mapped test 
device having a switch for selectively connecting one or more of the I/O cores to 
corresponding I/O driver models; a bus for transferring signals between the I/O 
controller and the switch; and a test operating system for controlling the switch. 

[0014] A second aspect of the present invention is a method for verifying an integrated 
circuit design comprising: providing an I/O controller connected to one or more I/O 
cores, the I/O cores part of the integrated circuit design; providing an external 
memory mapped test device having a switch for selectively connecting one or more of 
the I/O cores corresponding I/O driver models; providing a bus for transferring 
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signals between the I/O controller and the switch; providing a test operating system 
for controlling the switch; and simulating the integrated circuit design by running a 
test case on the test operating system. 

[001 5] A third aspect of the present invention is a program storage device readable by 

machine, tangibly embodying a program of instructions executable by the machine to 
perform method steps for verifying an integrated circuit design, the method steps 
comprising: providing an I/O controller connected to one or more I/O cores, the I/O 
cores part of the integrated circuit design; providing an external memory mapped test 
device having a switch for selectively connecting one or more of the I/O cores to 
corresponding I/O driver models; providing a bus for transferring signals between the 
I/O controller and the switch; providing a test operating system for controlling the 
switch; and simulating the integrated circuit design by running a test case on the test 
operating system- 
Brief Description of the Drawings 

[001 6] The features of the invention are set forth in the appended claims. The invention 
itself, however, will be best understood by reference to the following detailed 
description of an illustrative embodiment when read in conjunction with the 
accompanying drawings, wherein: 

[001 7] FIG. 1 illustrates an exemplary SOC that includes dedicated and muxed cores 
connected to external dedicated and muxed driver models and communicated 
with/controlled by an external memory mapped test device (EMMTD) in response to a 
test case; 

[001 8] FIG. 2 is a flowchart illustrating the method of switching the external muxed driver 
models illustrated in FIG. 1 ; 

[0019] FIG. 3 illustrates an exemplary SOC that includes dedicated and muxed cores 
connected to external dedicated and muxed driver models and communicated 
with/controlled by an EMMTD in response to a test case according to a first 
embodiment of the present invention; 

[0020] 

FIG. 4 is a flowchart illustrating the method of switching the external muxed driver 
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models illustrated in FIG. 3 according to the present invention; 



[0021] FIG. 5 is an exemplary software schematic representation illustrating switching 
control of the external muxed driver models illustrated in FIG. 3 according to the 
present invention; 

[0022] FIG. 6 illustrates an exemplary SOC that includes dedicated and muxed cores 
connected to external dedicated and muxed driver models and communicated 
with/controlled by an EMMTD in response to a test case according to a second 
embodiment of the present invention; and 

[0023] FIG. 7 is a schematic block diagram of a general-purpose computer for practicing 
the present invention. 

Detailed Description of the Invention 

[0024] The term "core" as used herein refers to a module of logic for an integrated circuit 
chip design of any degree of complexity, which may be used as a component of a 
SOC. The term "model" as used herein refers to a module of software representing an 
external I/O driver connected to I/O pins used in conjunction with the testing of a 
corresponding "core." For the purposes of the present invention, SOC and chip are 
equivalent terms. In its developmental stages, a core or model is typically embodied 
as a simulatable HDL program written at some level of abstraction, or in a mixture of 
abstraction levels, which can describe the function of the core prior to its actual 
physical implementation in silicon. Major levels of abstraction that are generally 
recognized include a behavioral level, a structural level and a logic gate level. A core 
or model may be in the form of a netlist including behavioral, structural and logic gate 
elements. Ultimately, after verification, design logic represented by a core or model is 
physically implemented in hardware. 

[0025] 1 j|| ustrates an exemplary SOC that includes dedicated and muxed cores 

connected to external dedicated and muxed driver models and communicated 
with/controlled by an external memory mapped test device (EMMTD) in response to a 
test case. In FIG. 1 , SOC 1 00 includes an embedded processor core 1 05, a memory 
controller core 1 1 0, a dedicated 1 394 core 1 1 5, a dedicated universal asynchronous 
receiver transmitter (UART) core 120, a muxed serial core 1 25, a muxed UART core 
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1 30, a muxed direct memory access (DMA) core 135 and a general purpose I/O core 
(GPIO) 140 (which is an I/O controller) all coupled to a system bus 145. Additionally, 
muxed serial core 125 is connected to directly to GPIO core 140 by bus 145, muxed 
UART core 1 30 is connected to directly to GPIO core 140 by a bus 1 50 and muxed 
DMA core 135 is connected directly to GPIO core 140 by a bus 1 55. 

[0026] Memory controller core 1 1 0 is coupled via a memory bus 1 60 to an external 
memory model 1 65. An EMMTD 1 70 is also coupled to memory bus 1 60. 

[0027] Dedicated 1 394 core 1 1 5 is coupled to a dedicated 1 394 model 1 75 via a bus 
1 80. Dedicated UART core 1 20 is coupled to a dedicated UART model 1 85 by a bus 
1 90. Dedicated 1 394 model 1 75 is coupled to EMMTD 1 70 by a bus 195. Dedicated 
UART model 1 85 is coupled to EMMTD 1 70 by a bus 200. 

D [0028] GPIO 140 is coupled to a GPIO bus 205. A muxed UART model 210 is coupled to 
ffl GPIO bus 205 by a bus 21 5 and coupled to EMMTD 1 70 by a bus 220. A muxed serial 

fi mode\ 225 is coupled to GPIO bus 205 by a bus 230 and coupled to EMMTD 1 70 by a 

Cn bus 235. A muxed DMA model 240 is coupled to GPIO bus 205 by a bus 245 and 

SI coupled to EMMTD 1 70 by a bus 250. GPIO bus 205 is also coupled to EMMTD 1 70 by 

L a bus 255 to allow direct read/write access to I/O pins. 

^£ 
ffl 

q [0029] For the purposes of the present invention, SOC 1 00 is intended to include 
tZ embodiments in any known form of logic design, including simulatable HDL modules 

nj and net| ists. In one example, embedded processor core 1 05, memory controller core 

1 1 0, dedicated 1 394 core 1 1 5, dedicated UART core 120, muxed serial core 1 25, 
muxed UART core 1 30, muxed DMA core 1 35, GPIO core 140, external memory model 
165, EMMTD 170, dedicated 1394 model 175, dedicated UART model 185, muxed 
UART model 210, muxed serial model 225 and muxed DMA model 240 are HDL 
modules being simulated by a test operating system (TOS) and memory bus 1 60, GPIO 
bus 205 and buses 145, 150, 1 55, 180, 190, 215, 220, 230, 235, 245, 250 and 255 
represent virtual connections implemented by code specifications. 

[0030] The aforementioned TOS is also known as an automated test operating system or 
AutoTOS. 

[0031] Dedicated 1394 model 175, dedicated UART model 185, muxed UART model 210, 
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muxed serial model 225 and muxed DMA model 240 are external to SOC 100 and are 
the I/O pin driver simulation models needed to test the SOC. 

[0032] Also shown in FIG. 1 is a test case 260, representing computer-executable 

instructions loaded into external memory model 1 65 and executed by embedded 
processor core 1 05 to perform verification of SOC 1 00. Test case 260 is a set of 
computer-executable instructions, which generate stimuli to verify the design of SOC 
1 00. The application of the test case typically produces, as output, result data 
representing the response of the simulated design, which is compared to expected 
results, to determine whether the design functions as expected. The design may 
subsequently be revised to improve performance or de-bug errors. 

[0033] GPIO core 1 40 can switch one of buses 1 45, 1 50 and 1 55 to GPIO bus 205 based 
upon how the GPIO core is programmed. If for example, bus 1 50 is muxed, then 
muxed UART core 1 30 is connected to muxed UART model 21 0 and muxed UART 
model 21 0 is connected to EMMTD 1 70. Muxed UART model 210, muxed serial model 
225 and muxed DMA model 240 are tri-state driver models. Tri-stating drivers allow 
one model (or more depending upon how the I/O pins are allocated) to take control of 
GPIO bus 205 while the other models are tri-stated. The method of switching models 
is illustrated in FIG. 2 and described below. By contrast, dedicated 1394 core 1 1 5 and 
dedicated UART core 120 are always connected to EMMTD 1 70 through dedicated 
1 394 model 1 75 and dedicated UART model 1 85, respectively. 

[0034] Embedded processor 1 05 starts/stops dedicated 1 394 model 1 75 and dedicated 
UART model 1 85 via system bus 145, memory controller 1 1 0, memory bus 1 60, 
EMMTD 170 and buses 195 and 200 respectively. Embedded processor 105 
starts/stops muxed UART model 21 0, muxed serial model 225 and muxed DMA 
model 240 via system bus 1 45, memory controller 1 1 0, memory bus 1 60, EMMTD 1 70 
and buses 220, 235 and 250 respectively. Dedicated UART model 185 and muxed 
UART model 210 are not required to be identical. 

[0035] while two dedicated cores and their corresponding dedicated models (dedicated 
1 394 core 1 1 5 and dedicated 1 394 model 1 75 and dedicated UART core 1 20 and 
dedicated UART model 1 85) are illustrated in FIG. 1 , more or less and different 
combinations of dedicated cores and dedicated models may be employed. Also, while 
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three muxed cores and their corresponding muxed models (muxed serial core 125 
and muxed serial model 225, muxed UART core 130 and muxed UART model 210 and 
muxed DMA core 1 35 and muxed DMA model 240) are illustrated in FIG. 1 , more or 
less and different combinations of muxed cores and muxed models may be employed. 

[0036] FIG. 2 is a flowchart illustrating the method of switching the external muxed driver 
models illustrated in FIG. 1 . In step 270, the TOS is programmed to allocate the 
required CPIO pins in order for multiple tests to be run concurrently. For example, if 
GPIO core 140 (see FIG. 1) has 1 5 pins, then a muxed core requiring 7 pins and a 
muxed core requiring up to 8 pins can be run together. Obviously, some muxed cores 
may require so many pins that they must be run alone. 

[0037] In step 275, the connection between EMMTD 170 (see FIG. 1) and the muxed 

models for which pins have been allocated in step 270 is programmed. The code for 
this programming step is generally unique to each of the models. 

[0038] In step 280, GPIO core 140 (see FIG. 1) is programmed to connect the GPIO to the 
muxed cores for which pins have been allocated in step 270. The code for this 
programming step is generally unique to each of the cores for which pins have been 
allocated. 

[0039] In step 285, the corresponding models for the cores for which pins have been 
allocated in step 270 are programmed to turn on. If these models are not tri-state 
driver models then code must be modified to make the models tri-state driver 
models. 

[0040] In step 290, test case 260 (see FIG. 1) is programmed to run. 

[0041 ] In step 295, the corresponding models for the cores for which pins have been 
allocated in step 270 are programmed to turn off. 

[0042] In step 300, the disconnection of EMMTD 170 (see FIG. 1) from the muxed cores 
for which pins have been allocated in step 270 is programmed. 

[0043] In step 305, GPIO core 140 (see FIG. 1) is programmed to disconnect the GPIO 
from the muxed cores for which pins have been allocated in step 270. 
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[0044] In step 310, the TOS is programmed to free the GPIO pins allocated in step 270. 

[0045] FIG. 3 illustrates an exemplary SOC that includes dedicated and muxed cores 
connected to external dedicated and muxed driver models and communicated 
with /controlled by an EMMTD in response to a test case according to a first 
embodiment of the present invention. The present invention essentially modifies 
EMMTD 170 (see FIG. 1) as well as external muxed I/O models and the connections 
between them. In FIG. 3, SOC 100 includes embedded processor core 105, memory 
controller core 1 1 0, dedicated 1 394 core 1 1 5, dedicated universal asynchronous 
receiver transmitter (UART) core 1 20, muxed serial core 125, muxed UART core 1 30, 
muxed dynamic memory allocation (DMA) core 1 35 and general purpose I/O core 
(GPIO) 140 (which is an I/O controller) all coupled to system bus 145. Additionally, 
muxed serial core 125 is connected to directly to GPIO core 140 by bus 145, muxed 
UART core 1 30 is connected to directly to GPIO core 140 by bus 1 50 and muxed DMA 
core 135 is connected directly to GPIO core 140 by bus 155. 

[0046] Memory controller core 1 1 0 is coupled via memory bus 1 60 to an external 

memory model 1 65. An EMMTD 1 70A is also coupled to memory bus 1 60. EMMTD 
170A includes an address register 312 and an EMMTD switch 31 5. 

[0047] Dedicated 1 394 core 1 1 5 is coupled to dedicated 1 394 model 1 75 via bus 1 80. 
Dedicated UART core 1 20 is coupled to a dedicated UART model 1 85 by bus 1 90. 
Dedicated 1 394 model 1 75 is coupled to EMMTD 1 70A by bus 1 95. Dedicated UART 
model 1 85 is coupled to EMMTD 1 70A by bus 200. 

[0048] GPIO 1 40 is coupled to GPIO bus 205. GPIO bus 205 is coupled to EMMTD switch 
31 5 by a bus 320. A muxed UART model 325 is coupled to EMMTD switch 31 5 by a 
bus 330 and coupled to address register 312 by a bus 335. A muxed serial model 340 
is coupled to EMMTD switch 315 by a bus 345 and coupled to address register 312 by 
a bus 350. A muxed DMA model 355 is coupled to EMMTD switch 31 5 by a bus 360 
and coupled to address register 31 2 by a bus 365. EMMTD switch 31 5 is also coupled 
to address register 31 2 by a bus 370 to allow direct read/write access to I/O pins. Bus 
370 may be considered as connected to an I/O model defining only direct pin 
connections. 
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[0049] For the purposes of the present invention, EMMTD 1 70A (including address 

register 312 and switch 31 5), muxed UART model 325, muxed serial model 340 and 
muxed DMA model 355 are HDL modules being simulated by the TOS and buses 320, 
330, 335, 345, 350, 360, 365 and 370 represent virtual connections implemented by 
code specifications. 

[0050] Dedicated 1 394 model 1 75, dedicated UART model 1 85, muxed UART model 325, 
muxed serial model 340 and muxed DMA model 355 are external to SOC 100 and are 
the I/O driver simulation models needed to test the SOC. 

[0051] Also shown in FIG. 3 is test case 260, representing computer-executable 

instructions loaded into external memory model 165 and executed by embedded 
processor core 1 05 to perform verification of SOC 1 00. 

[0052] CPIO core 140 can selectively switch buses 145, 1 50 and 1 55 to GPIO bus 205 
based upon how the GPIO core is programmed. If for example, bus 150 is muxed, 
then muxed UART core 1 30 is connected via GPIO bus 205 and bus 320 to EMMTD 
switch 31 5. EMMTD switch 315 is also programmed to selectively connect bus 320 to 
bus 330 allowing muxed UART model 325 to be connected to EMMTD 170A and 
address register 312. EMMTD switch 31 5 allows one model to take control of GPIO 
bus 205. EMMTD switch 31 5 is a controlled by the TOS and eliminates the need for 
tri-state control. Though EMMTD switch 31 5 is illustrated in FIG. 3 as a single throw 
switch switching only one driver model at a time, as the EMMTD switch is simply a set 
of logic gates, the EMMTD switch may selectively connect more than one of the driver 
models to bus 320 upon I/O pin allocation. 

[0053] Embedded processor 105 starts/stops dedicated 1394 model 175 and dedicated 
UART model 1 85 via system bus 1 45, memory controller 1 1 0, memory bus 1 60, 
EMMTD 1 70A, and buses 195 and 200 respectively. Embedded processor 105 
starts/stops muxed UART model 325, muxed serial model 340 and muxed DMA 
model 355 via system bus 1 45, memory controller 1 1 0, memory bus 1 60, EMMTD 
1 70A and buses 335, 350 and 365 respectively. Dedicated UART model 1 85 and 
muxed UART model 325 may be identical. In fact, all driver models having the same 
function and pin counts may be identical whether or not they are "dedicated" or 
"muxed." 
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[0054] The TOS uses a systems definition file (SDF) to specify which cores use GPIO bus 
205 and what bits of the GPIO bus are being used. With this information TOS code can 
be automatically generated to allocate GPIO bits, program GPIO core 140 and set 
EMMTD switch to the correct model and release the GPIO pins. Automatic generation 
of TOS code may be performed by an AUTO-TOS as described in the cross-referenced 
applications. The method of switching models is illustrated in FIG. 4 and described 
below. 

[0055] While two dedicated cores and their corresponding dedicated models (dedicated 
1 394 core 1 1 5 and dedicated 1 394 model 1 75 and dedicated UART core 1 20 and 
dedicated UART model 1 85) are illustrated in FIG. 3, more or less and different 
combinations of dedicated cores and dedicated models may be employed. Also, while 
three muxed cores and their corresponding muxed models (muxed serial core 125 
y and muxed serial model 340, muxed UART core 1 30 and muxed UART model 325 and 

y! muxed DMA core 135 and muxed DMA model 355) are illustrated in FIG. 3, more or 

fJl less and different combinations of muxed cores and muxed models may be employed. 

SJj [0056] FIG. 4 is a flowchart illustrating the method of switching the external muxed driver 

models illustrated in FIG. 3 according to the present invention. EMMTD switch 315 
y (see FIG. 3) allows a general test case to be used for all multiplexed cores. To reuse 

Q the general test case the proper conditions must be setup prior to starting the test so 

II that the connection is ready and dedicated to the test. Because signals are multiplexed 

■is*?-? 

III both inside and outside SOC 100 (see FIG. 3), programming must be performed to 
establish this connection. 

[0057] In step 375, the TOS code to allocate the required GPIO pins in order for multiple 
tests to be run concurrently is automatically generated. For example, if GPIO core 140 
(see FIG. 3) has 15 pins, then a muxed core requiring 7 pins and a muxed core 
requiring up to 8 pins can be run together. Obviously, some muxed cores may require 
so many pins that they must be run alone. 

[0058] In step 380, EMMTD switch 31 5 (see FIG. 3) is programmed to connect the GPIO 
core 140 (See FIG. 3) to the muxed models corresponding to the muxed cores of step 
375 for which pins have been allocated in step 375. The TOS code for this 
programming step is automatically generated. TOS. 
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[0059] In step 385, GPIO core 140 (see FIG. 1) is programmed to connect the GPIO to the 
muxed cores for which pins have been allocated in step 375. The TOS code for this 
programming step is automatically generated. TOS. 

[0060] In step 390, test case 260 (see FIG. 3) is programmed to run. 

[0061] In step 395, EMMTD switch 31 5 (see FIG. 3) is programmed to disconnect the GPIO 
140 (See FIG. 3) from the muxed models for which pins have been allocated in step 
375. The TOS code for this programming step is automatically generated. 

[0062] In step 400, GPIO core 140 (see FIG. 1) is programmed to disconnect the GPIO 

from the muxed cores for which pins have been allocated in step 375. The TOS code 
for this programming step is automatically generated. 

[0063] In step 405, the TOS code to free the GPIO pins allocated in step 375 is 
automatically generated. 

[0064] Implementation of the method illustrated in FIG. 4 and described above, requires a 
user to simply declare a GPIO pin allocation in the SDF file of the TOS as a resource for 
a specific test case. For example, if the core is connected to GPIO Altl , bit2 and the 
GPIO is connected to EMMTD Byte 3, bit 6, then the declaration is " connect GPIO altl , 
bit 2 to EMMTD byte 3, bit 6." The TOS code is generated to allocate the pins and to 
setup the connection and subsequently release the connection following the test 
assuring concurrency of multiplexed test cases in a system verification environment. 

[0065] FIG. 5 is an exemplary software schematic representation illustrating switching 
control of the external muxed driver models illustrated in FIG. 3 according to the 
present invention. In FIG. 5, running on embedded processor 105 (see FIG. 3) is chip 
specific code 41 0 and generic code 41 5. Chip specific code 410 includes a TOS kernel 
420 and TOS chip specific code 425. Running on generic code 41 5 is an EMMTD driver 
430 including an address map 435, a UART application 440 and a UART driver 445, a 
DMA application 450 and a DMA driver 455 and a serial application 460 and a serial 
driver 465. Address map 435 corresponds to address register 31 5 of FIG 3. Chip 
specific code 425 writes bit 0 of address map 435 in order to set EMMTD switch 31 5 
(see FIG. 3). UART application 440, DMA application 450 and serial application write 
bits 1 through 7 of address map 435 in order to control start/ run/ stop of muxed 
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UART model 325, muxed DMA model 355 and muxed serial model 340 of FIG. 3 
respectively. FIG. 6 illustrates an exemplary SOC that includes dedicated and muxed 
cores connected to external dedicated and muxed driver models and communicated 
with/controlled by an EMMTD in response to a test case according to a second 
embodiment of the present invention. FIG. 6 differs from FIG. 3 only in that the 
EMMTD function is distributed. 

[0066] In FIG. 6, EMMTD 1 70B is coupled to dedicated 1 394 model 1 75 and dedicated 
UART model 1 85. A first module 470 includes an EMMTD module 1 70C (comprising 
address register 312C and an EMMTD switch 31 5C) and a muxed 1394 model 325 
coupled between address register 31 2C and EMMTD switch 31 5C. A second module 
475 includes an EMMTD module 1 70D (comprising an address register 31 2D and an 
EMMTD switch 31 5D) and a muxed serial 1 394 model 340 coupled between address 
register 31 2D and EMMTD switch 315D. A third module 480 includes an EMMTD 
module 1 70E (comprising an address register 31 2E and an EMMTD switch 31 5E) and a 
muxed DMA model 355 coupled between address register 31 2E and EMMTD switch 
31 5E. A fourth module 485 includes an EMMTD module 1 70F comprising an address 
register 31 2F and an EMMTD switch 31 5F. EMMTDs 170C, 170D, 170Eand 170Fare 
coupled to memory bus 160 by a bus 490. Depending upon pin allocation, one or 
more of EMMTD switches 31 5C, 31 5D, 31 5E and 31 5F may be programmed to 
connect corresponding I/O driver models to bus 320. 

[0067] Generally, the method described herein with respect to switching external models 
in an automated system-on-chip integrated circuit design verification system is 
practiced with a general-purpose computer and the method may be coded as a set of 
instructions on removable or hard media for use by the general-purpose computer. 
FIG, 7 is a schematic block diagram of a general-purpose computer for practicing the 
present invention. In FIG. 7, computer system 500 has at least one microprocessor or 
central processing unit (CPU) 505. CPU 505 is interconnected via a system bus 510 to 
a random access memory (RAM) 51 5, a read-only memory (ROM) 520, an input/output 
(I/O) adapter 525 for a connecting a removable data and/or program storage device 
530 and a mass data and/or program storage device 535, a user interface adapter 
540 for connecting a keyboard 545 and a mouse 5 50, a port adapter 555 for 
connecting a data port 560 and a display adapter 565 for connecting a display device 
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[0068] ROM 520 contains the basic operating system for computer system 500. The 

operating system may alternatively reside in RAM 51 5 or elsewhere as is known in the 
art. Examples of removable data and/or program storage device 530 include magnetic 
media such as floppy drives and tape drives and optical media such as CD ROM drives. 
Examples of mass data and/or program storage device 535 include hard disk drives 
and non-volatile memory such as flash memory. In addition to keyboard 545 and 
mouse 550, other user input devices such as trackballs, writing tablets, pressure 
microphones, light pens and position-sensing screen displays may be connected to 
user interface 540. Examples of display devices include cathode-ray tubes (CRT) and 
liquid crystal displays (LCD). 

[0069] A computer program with an appropriate application interface may be created by 
one of skill in the art and stored on the system or a data and/or program storage 
device to simplify the practicing of this invention. In operation, information for or the 
computer program created to run the present invention is loaded on the appropriate 
removable data and/or program storage device 530, fed through data port 560 or 
typed in using keyboard 545. 

[0070] The present invention of a design verification system reduces the amount of chip 
specific design software required for verification of pin-muxing and makes the 
muxing of signals through a CPIO core transparent to setting up an SOC verification 
environment. 

[0071] The description of the embodiments of the present invention is given above for 

the understanding of the present invention. It will be understood that the invention is 
not limited to the particular embodiments described herein, but is capable of various 
modifications, rearrangements and substitutions as will now become apparent to 
those skilled in the art without departing from the scope of the invention. Therefore it 
is intended that the following claims cover all such modifications and changes as fall 
within the true spirit and scope of the invention. 
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